-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Association History Processing (Part 2) #618
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
7c48f72
to
1068a6b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems good to me -- in an ideal world i'd like to see less boxing, but I like the builder-esque strategy of the IdentityAction interface for the log actions.
} | ||
|
||
#[derive(Clone, Debug, PartialEq)] | ||
pub enum SignatureKind { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does it make sense to handle an Other(String)
kind?
For instance, in the case that someone wants to implement their custom signature type, or would that break too many assumptions?
pub struct CreateInbox { | ||
pub nonce: u64, | ||
pub account_address: String, | ||
pub initial_address_signature: Box<dyn Signature>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we boxing all these Signatures
to make it easier for ffi?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly out of expedience, although I think it does make FFI easier.
If we can come up with an unboxed solution that works everywhere I'm all for it.
1068a6b
to
095ddb7
Compare
Summary
TODO